home *** CD-ROM | disk | FTP | other *** search
- Path: fido.asd.sgi.com!austern
- From: clamage@Eng.Sun.COM (Steve Clamage)
- Newsgroups: comp.std.c++
- Subject: Re: Inherent C++ problem??
- Date: 06 Feb 1996 11:40:20 PST
- Organization: Sun Microsystems Inc.
- Approved: austern@isolde.mti.sgi.com
- Message-ID: <4f8adk$fn6@engnews1.Eng.Sun.COM>
- References: <199602060648.HAA19423@mail.pi.se>
- Reply-To: clamage@Eng.Sun.COM
- NNTP-Posting-Host: isolde.mti.sgi.com
- X-Original-Date: 6 Feb 1996 19:33:08 GMT
- X-Auth: PGPMoose V1.1 PGP comp.std.c++
- iQBVAwUBMReus0y4NqrwXLNJAQH/8QH/X+sqT5jVVwIQquauZ6mbTYNNtcaTfvDN
- JhiyU1FRWw0ZNIqFBqwD+Qh3iXwV/ls9v8oDqE0aSpSZMPW2QtUhog==
- =MvkZ
- Originator: austern@isolde.mti.sgi.com
-
- In article HAA19423@mail.pi.se, william.mc@pi.se (William McIlhagga) writes:
-
- >1) The standard says that an implementation *may* get rid of some copy
- >constructors; it does not demand it. Thus the indeterminism lies in the fact
- >that the programmer does not know whether this has happened to their code,
- >unless the compiler is kind enough to say so (compilers are the strong
- >silent type, and don't usually tell you anything about what they're thinking)
-
- >2) Removing copy constructors is intended as an optimisation. But
- >optimisations should never change the meaning of a program - that is, the
- >program should produce the same results with and without the optimisation.
- >Clearly, removing "irrelevant" copy constructors is a different kind of
- >thing altogether.
-
- >I think this part of the standard is a little dangerous. I accept that
- >removing copy constructors is a useful optimisation however (though I
- >haven't seen any benchmarks to show how big a speedup you get - perhaps
- >someone could post some to convince us all that it's worthwhile). There are
- >a few things that might improve the situation:
-
- >1) if an implemention removes a copy constructor, the standard should demand
- >that it issues a warning message (if the user desires...). Though I guess
- >most people will turn this warning off after a couple of hours, so maybe
- >that's not so smart.
-
- >2) the standard should include some specified way of switching off the
- >removal of copy constructors. If it's in the standard then it's
- >transportable, so no problems there. Perhaps some ugly #pragma or something?
-
- The problem is not just that a copy constructor might be elided in code like
- T t = T(x); // T is some type
- Whether the temp gets elided might depend on the optimization level that
- was set or whether debugging is turned on.
-
- The compiler is also allowed to create extra temps where convenient.
-
- In addition, unless you are EXTREMELY knowledgeable about very fine
- semantic details of C++, you will be unable to determine reliably where
- temps must be created according to the language semantics. Even if you
- have this deep knowledge, it takes a very careful analysis of even a
- simple expression like
- x = a + b + c;
- to determine where (if anywhere) temps must be created. It depends on
- the parameter types of the functions called, which further depends on
- the way overloaded function calls are resolved.
-
- I really don't think you want to get messages about every temp that
- was created and every optional temp that was omitted. I also don't think
- you want to try to tell the compiler where it should and where it should
- not omit unneeded temps.
-
- Instead, the basic design rule is that program correctness should not
- depend on exactly how many temps get created. Even with the compiler
- options you are asking for, a program with such a dependence would be
- unmaintainable.
- ---
- Steve Clamage, stephen.clamage@eng.sun.com
- ---
- [ comp.std.c++ is moderated. Submission address: std-c++@ncar.ucar.edu.
- Contact address: std-c++-request@ncar.ucar.edu. The moderation policy is
- in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]
-